A programmable logic device (PLD) is an electronic component used to build configurable digital circuits. Unlike a logic gate, which has a fixed function, a PLD has an undefined function at the time of manufacture. Before the PLD can be used in a circuit it must be programmed (i.e., configured). One variant of a PLD is a field programmable gate array (FPGA), which uses a grid of logic gates. The programming or configuration of the FPGA is done by a user, not by the manufacturer.
FIG. 1 shows a prior art configuration 100 for a programmable logic device (PLD) 10 such as an FPGA. The PLD 10 includes programmable logic 11, also known as an application logic, which typically comprises (1) logic blocks (2) routing lines and programmable interconnection points for routing signals around the PLD 10, and (3) input/output blocks for driving signals between the routing lines and the external pins of the PLD. The logic block contains a lookup table and combinatorial logic function generators as well as flip flops for storing lookup table outputs and other values, and multiplexers and logic gates for enhancing the logic ability of the programmable logic.
The PLD 10 also includes a configuration memory 12, e.g., a static random access memory (RAM), for turning on routing transistors, controlling multiplexers, storing lookup tables and controlling the input/output blocks, all of this for the purpose of configuring the PLD to perform the functionality desired by the designer(s). Bus 16 connects configuration memory 12 to programmable logic 11 and is typically a distributed set of control lines located throughout the PLD. Some Xilinx products (e.g. XC6200) have included a bus 17 by which programmable logic 11 causes a configuration logic 14 to send programming information to configuration memory 12. A bus 18 allows communication between the configuration logic block 14 and the configuration memory 12. In particular, it carries addresses to select configuration frames in memory 12, control signals to perform write and read operations, and data for loading into configuration memory 12 or reading back from configuration memory 12. The configuration logic 14 also responds to a configuration bitstream from an external source 15 on configuration access port 21. The bitstream on configuration access port 21 is treated as words, for example 32-bit words. Several of the words, usually at or near the beginning of the bitstream, are used for setting up the configuration process and include, for example, length of a configuration memory frame, and starting address for the configuration data. One such a structure is described by Kean in U.S. Pat. No. 5,705,938.
PLD 10 further includes a Joint Test Action Group (JTAG) logic block 13 for interfacing with a JTAG port 20 that allows for testing the board in which the PLD is placed. The JTAG logic block 13 implements the IEEE standard 1532, which is a superset of the IEEE standard 1149.1. JTAG allows debugging of a design at the board level. The configuration logic 14 also interfaces with the JTAG logic block 13 through a bus 19, which allows communication between the configuration logic 14 and JTAG logic block 13 so that the JTAG port can be used as another configuration access port. The configuration logic block 14 receives instructions and data, and processes the data according to the instructions. These instructions come into configuration logic 14 as a bitstream. An instruction, or header, is usually followed by data to be acted upon.
The configuration logic 14 typically performs a cyclic redundancy check on a configuration bitstream coming in (see Erickson, U.S. Pat. No. 5,321,704 incorporated herein by reference), reads header bits indicating the frame length of the part being configured and the word count of the configuration data, reads address instructions identifying where to load configuration data, collects frames of configuration data and loads them into columns of configuration memory 12 indicated in the addresses. The configuration logic 14 also controls the readback of configuration data and flip flop values from configuration memory 12 to an external location. In a Virtex FPGA available from Xilinx, Inc., the readback can be done through either a JTAG port 20 or through a configuration access port 21. The configuration logic 14 can also receive configuration data from the programmable logic 11. Prior art PLD configurations in which part of the PLD configures another part of the PLD are disclosed in Kean, U.S. Pat. No. 5,705,938 and Young et al., U.S. Pat. No. 5,914,616, which are both incorporated herein by reference.
Because the PLD 10 is configured by data stored in configuration memory 12 that must be loaded on power-up, the privacy of the design can easily be violated by an attacker who monitors the data on the configuration access port 21, e.g. by putting probes on board traces.
FIG. 2 shows a block diagram of a prior art PLD configuration having a decryption capability. As with the PLD 10 of FIG. 1, the PLD 10 of FIG. 2 is configured by a static RAM memory that must be loaded on power-up. However, with the PLD 10 of FIG. 2, the configuration data is protected as it is being loaded into the device by encrypting the configuration data. The data received from the external source 15 is encrypted. The key for decrypting the configuration data is stored in a key memory 23 and is used by a decryptor 24 within the PLD 10 to decrypt the configuration data. The PLD 10 is then configured using the decrypted configuration data. FIG. 2 shows an approach where the key memory 23 is accessed using a bus 25 from the JTAG access port 20. The bus 25 carries data, addresses, and control signals to perform write and read operations and allows programming of the decryption keys from the JTAG port 20. A bus 26 can also be used for programming of the decryption keys from the configuration port 21. The bus 26 carries security data from key memory 23 to configuration logic 29. A bus 27 carries encrypted configuration data from configuration logic 29 to the decryptor 24 and carries decrypted configuration data back to the configuration logic 29. A bus 28 allows the decryptor 24 to access the keys for decrypting data. When the PLD configuration of FIG. 2 is being loaded with encrypted data, an attacker who monitors the bitstream as it is being loaded receives only the encrypted bitstream and cannot learn the user's design by this method.
FIG. 3 depicts a block diagram of a prior art PLD configuration for testing a PLD 10, which is referred to as a unit under test (UUT). For the sake of simplicity, the logic components previously shown and described in FIGS. 1 and 2 for programming the PLD 10 are not shown in FIG. 3. In order to test the PLD 10 according to the prior art, an embedded test logic 302 is created on the PLD The embedded test logic 302 is designed to monitor logic signals of interest 304 of an application logic 11 that typically interfaces with one or more external devices 306. As depicted in FIG. 3, the PLD 10 also includes a JTAG port 20 that provides an interface to a computer/logic analyzer 308 for controlling and receiving output from embedded test logic 302 over bus 310. The embedded test data pertaining to the monitored signals of interest 304 is stored in a local storage 312. A user of a display/keyboard 314 attached to the computer/logic analyzer 308 can examine the embedded test data stored in the local storage 312. Users of other computers connected to the computer/logic analyzer 308 via a network 316 can also access the embedded test data stored in local storage 312. An optional access control layer 318 can be implemented that involves user access control via passwords and may involve encryption or other protection of the embedded test data.
According to the prior art approach, once the testing is complete, the embedded test logic 302 is removed from the PLD 10, as depicted in FIG. 4, to allow the PLD 10 to function for its intended purpose without the embedded test logic 302, thereby preventing an attacker from learning about the PLD 10 functionality based on embedded test data. The removal of the embedded test logic 302, however, changes the PLD's circuit level design, thereby invalidating verification and validation results from the testing of the PLD 10.
Therefore, there exists a need for PLD configurations that operate as intended while maintaining their validation and verification testing status.